Subject: Directory SIG Report, 9/93 CIW

From: "Mel Jones (Tie: 444-4363)" <[email-masked]>
Date: Fri, 17 Sep 93 13:11:30 EDT

Directory SIG Report -- September '93 Meeting, Seattle
------------------------------------------------------
The directory SIG met and worked through a number of discussion
topics.  See the detailed minutes (below) for a complete report.
In general, the CIW agreed to 1) continue the direction of using
the Set_Partner_ID call and 2) allow specification of a DN or
PFID.  A proposal for specification of the directory name space
(e.g., OSF or X.500) will be distributed shortly.  Advancement of
the directory proposal will (hopefully) follow the security SIG,
i.e., interim AP status in October/November and CP status at the
December meeting.

Detailed Directory SIG Meeting Report
-------------------------------------
The initial meeting of the directory SIG on Wednesday worked
through discussion items that had come up during the June CIW and
in internet traffic since the meeting.  The results of that
discussion are shown below under "Wednesday Discussion".  On
Thursday we had a second meeting, which created a six-item agenda
(some were resolved; some topics needed further work).  The six
points are shown below under "Thursday Discussion" and were
presented Friday morning at the plenary session.

Wednesday Discussion
--------------------
W1.  A proposal was made to include the PSAP in the program
object.  After much discussion, it was agreed that this
information should not be contained in the program object.  The
AE_qualifier and AP_title are sufficient information to pass to
OSI for establishment of a logical connection (i.e.,
association).  The OSI implementation might then go to a directory
to retrieve the PSAP, but specification of how this occurs is outside
the realm of CPIC.

W2.  There was a significant amount of discussion on the varying
levels of "function" that are available from a directory, and how
much of that function should be included in CPI-C.  A pyramid
chart showing increasing levels of functionality was shown.  The
top levels of the pyramid were agreed upon as:

  Top:  No directory interaction at all; program accesses directory itself
        and then uses Set calls to give information to CPIC.
Top-1:  Program specifies DN pointing to a single program installation.
Top-2:  Program specifies PFID pointing to multiple program installations,
        all representing the same functionality (e.g., LOTUS123)
        (This was recognized as a special case of the program doing a search
        on an object attribute of PFID.)

The functionality below "Top-2" was not as clearly defined, but
some examples of the function might be specification of a
relative DN, specification of a general program attribute for
searching, specification of an object_ID for searching,
specification of strings for searching, wildcards, etc.

The placement of a horizontal "dotted line" across the pyramid to
indicate the level of function that should be in CPIC was
discussed at length.  Although an inclination to move the dotted
line upwards was expressed by some developers ("let them use
sets" -- and an inclination to move the dotted line downwards was
expressed by others ("the program should only use one interface")
-- a consensus position was reached that the line should be left
as it is defined in the current directory proposal, i.e., placed
to include Sets, DN, and PFID.  Additional functionality was left
as a work-item for future enhancements and the SIG agreed that it
would be a good thing to create the list of additional function
(see Thursday discussion).

W3. The method of accessing the directory, or how the program would
provide the DN or PFID, was discussed at some length.  The two methods
proposed were the existing Set_Partner_ID call or a new CMINITA call.
Discussion on this point was deferred to the Thursday meeting.

W4.  The need (or non-need) of specifying a "directory name space"
qualifier for the DN was discussed.  Specifically, the question
is whether a DN is enough, or should there be some other
qualifier that would indicate the DN is drawn out of an ISO
distinguished-name space, an OSF directory namespace, or some future
as yet undefined namespace (e.g., "Y.600").

The argument for not including such a qualifier is that the
program gives CPIC a string and the implementation can use it in
whatever directory is available.  Precedent arguments for the
"magic" resolution of sym-dest-names in today's CPI-C were
stated.  It would be up to the implementation to resolve multiple
directories.

The argument for including the qualifier is that today's system
of one directory is tomorrow's merged-company system of two
directories, with possible name-space-collision problems.  A
qualifier to indicate the name-space would remove collisions and
allow for easy migration.  A further argument for including such
a qualifier is that it could be used to handle encoding
differences (e.g., "OSF-local-encoding" or "OSF-UNICODE".
Unfortunately discussion of this topic was put off until Thursday
(and then not completed), so no consensus on this point was
reached.  A proposal showing how such a qualifier could be added
to the existing proposal will be distributed for interim
discussion (hopefully before 10/1/93).

Thursday Discussion
-------------------
There were six discussion topics presented as an agenda for the
Thursday session.  Each is listed below with the results (or
non-results) arrived at.

T1.  What method of program access should be used -- Set_Partner_ID
or CMINITA?

The consensus position eventually reached, first on Thursday and
then later by the CIW as a whole on Friday, was to use
Set_Partner_ID.

T2.  What level of function should the current proposal contain?

The consensus position was that the CIW (the day before) agreed
to leave the "dotted line" where it is.  Functionality should
include specification of a DN or PFID.  Programs requiring
further functionality should access the directory directly.  See T3 for
further discussion.

T3. What is the list of follow-on functionality (below the
"dotted line") and what is the work required for each new
function, as well as possible value to the program?

No discussion of this topic occurred.  A list was created by the
SIG chair after the meeting and presented to the plenary session
Friday morning, but there was no discussion of the contents.
Review (and enhancement) of the list, along with determining
effort/value, is left as a future work item.  Here is the list
presented on Friday:

 - specification of a relative DN
 - specification of a particular attribute
 - specification of an object_ID for an attribute
 - specification of an object-ID plus a string for search
 - specification of a generic string for search
   .
   .
   .

T4. Should the CIW define an expected "minimum" protocol boundary
between the CPIC implementation and the directory?  If so, what
does that protocol boundary look like?

There was some discussion of this topic.  It was noted that the
DSNS interface (document in the appendix, which closely resembles
OSF's NSI interface) might be a beginning candidate for definition
of such a protocol boundary.  Proposals for other faces of such
an interface were solicited.

T5. Should there be a qualifier to the DN (e.g., OSF or X.500)?

No discussion of this topic.  The SIG chair hopes to distribute a
proposal for including this function (which was part of the
Boeing CMINITA proposal) into the existing directory proposal.

There was some discussion about DN versus RDN.  Two (possibly
conflicting) pieces of information were provided:  1.) That a
program can pass either a DN or RDN to the OSF directory and no
qualifier is required, and 2) that naming conditions exist where
the system can not know whether or not the passed value is a DN
or RDN (and hence might prepend when not needed, or vice versa).
More research on this subject is required.

T6. Should the appendix in the current proposal showing
DCE-specific extensions and objects be removed from the manual?

It was agreed that the appendix was useful and should remain.
The main reason was that it is valuable to implementers as a
guide of how they might work with DCE.  The lack of a parallel
appendix showing how to work with a full X.500-compliant
directory was deplored; contributions were solicited.

Conclusion
----------
The directory SIG had a lively and productive meeting at the
September CIW.  Progress was made on key discussion topics.  A
proposal to enhance the existing Set_Partner_ID proposal by
including a directory-name-space qualifier will be forthcoming.
If sufficient agreement can be reached, the SIG will attempt to
reach interim AP status on the existing (and modified) proposal,
thus allowing CP status at the December meeting (and inclusion of
the change pages with the document sent to X/OPEN).

Regards,
Mel Jones